In network communications, a network application (e.g. (Machine to Machine), M2M, cloud-based, etc.) or network server often requires a mechanism to initiate Internet Protocol (IP)-based communications with a device in a mobile or fixed network. However, destination IP address(es) and port(s) for addressing the target device IP are not always available to the entity that wishes to initiate the communication.
This may be due to the fact that a Network Address Translation (NAT), Network Address and Port Translation (NAPT) and/or firewall is maintaining a set of port forwarding rules that prevent inbound-initiated communication addressed to IP address and port combinations, unless a recent outbound communication from the same address and port combination has occurred.
When an outbound IP packet sent by a device traverses a NAT and/or firewall, a “pinhole” port forward rule (binding) is created in the NAT/firewall that allows incoming IP packets over the same address and port combination as the outbound initiating packet. The port forward rule is maintained for a period of time determined by the NAT and/or firewall, but typically not indefinitely. While the port forward rule is maintained, the network application or server can initiate the IP communications with the device over one of the available port forwarding rule address and port combinations.
When a device or network entity does not have prior knowledge of when a network application or server will initiate IP communications, the device or network may be required to maintain the IP connection and pinholes indefinitely (by sending keep-alive inbound and/or outbound IP packets for each address+port combination) to allow for inbound-initiated IP communications. However, this can be an inefficient use of network resources for mobile or fixed networks (e.g. if IPv4 dynamic addresses are limited) as well as for the device (e.g. if the device is battery powered).
For example, a current method for managing communication over a network is described below. A “hole punch msg” is sent from the device through the boundary device in the uplink (UL) direction to create a NAT Port and Address binding which temporarily allows messages in the downlink (DL) direction (addressed to the device) that match the Port and Address binding to traverse the NAT. Periodic keep-alives (KA's) are sent either by the device (UL KA's) or by the server (DL KA's) to prevent the NAT from releasing the Port and Address bindings. However, this method requires significant network and device resources, particularly as NAT's often release bindings every couple of minutes, and KA's typically need to be transmitted before the NAT binding release.
Another method of managing communication over a network is as follows. Once a connection is first established with the device from a server through a NAT/firewall, inbound keep-alive messages are sent at appropriate times by a network entity (e.g. a mediation server), based either on static or predictive application control in the network entity or sent by the network entity indefinitely. This approach may represent a more efficient use of network resources than the approach described above (e.g. Downlink typically has more capacity than uplink, mobile devices use extra power to transmit keep-alive messages but requires no additional power to receive keep-alive messages). However, this approach depends on the device first creating each pinhole before the network entity can then maintain the pinhole with inbound keep-alive messaging. Therefore, this approach is more complex because of the extra steps and coordination between the device and network entity.
Additionally, more complex methods used in SIP communication are defined in “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP),” C. Jennings et al., RFC 5626, Internet Engineering Task Force, October, 2009, where a client-to-server ping is first sent, followed by a server-to-client pong response.
Therefore there is a need for new method and apparatus which overcomes at least one of the problems in the prior art.
This background information is provided to reveal information believed by the applicant to be of possible relevance to the present technology. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present technology.